Would you be able to make it more "friendly" against changes in #2527?

Would you be able to make it more "friendly" against changes in #2527?

Did you mean to introduce CRcvBuffer::InsertInfo in this PR?

I'm not exactly convinced about adding this parameter so that it can be better displayed in logs. As for this, might be a better idea to instead move the whole log into the receiver buffer internals. In that PR the discrepancy is also detected on the level of insert() call, and it is also reported to the caller - not that the caller recognizes this by checking the range of the returned value.

move the whole log into the receiver buffer internals

I'm OK for this, but I don't want to change too much codes at once to keep a single PR small.

I understand, but if you provide changes that will make them harder to merge with my PR, it will be counter-productive. If this value is only used in logs, it should be able to be taken as before. Important would be if this value is to be used for some checks involved in the overall functionality.

You might consider borrowing the definition of CRcvBuffer::size(), which decreased from capacity() should give you the size of the remaining space in the buffer. If executed in the RcvQ:worker thread, it should even be unracy.

In #2527 there's something kinda better. There is an enum and localized to the buffer class.

Might make sense to declare an enum of the return values of the CRcvBuffer::insert(..) function.

In #2527 there's something kinda better. There is an enum and localized to the buffer class.

So to reduce conflicts, I would not do this in this PR. I will address other comments tomorrow.

Close due to #2546 has already removed getAvailRcvBufferSizeNoLock() from handleSocketPacketReception() and to avoid conflicts with #2527

@gou4shi1 Thank you for the PR anyway! These changes are to come one day. :)